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Abstract 


This Informational document records the history of discussions in the 
Problem WG during 2003 of how to resolve the problems described in 
the IETF Problem Statement. It decomposes each of the problems 
described into a few areas for improvement and categorizes them as 
either problems affecting the routine processes used to create 
standards or problems affecting the fundamental structure and 
practices of the IETF. Expeditious and non-disruptive solutions are 
proposed for the problems affecting routine processes. 


The document also lists suggested ways to handle the development of 
solutions for the structure and practices problems proposed in IETF 
discussions. Neither the working group nor the wider IETF has 
reached consensus on a recommendation for any of the proposals. This 
document therefore has no alternative but to suggest that the search 
for structure and practices solutions be handed back to the control 
of the IESG. 


While there was working group consensus on the processes for short- 
term and medium term improvements, there was no working group 
consensus on the proposals for longer-term improvements. This 
document therefore includes longer-term improvement proposals only as 
a matter of record; they must not be regarded as recommendations from 
the working group. 
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1. Introduction 


This document suggests processes to address several problems facing 
the Internet Engineering Task Force (IETF) that have been described 
in the IETF Problem Statement 
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This document begins with an outline of what are currently thought to 
be the purpose and core values of the IETF, and it offers a reminder 
of the good things about the IETF that we don’t want to lose in the 
process of solving our problems. 


Each of the problems described in the problem statement is analyzed 
and decomposed into a few areas for improvement. The areas for 
improvement appear to fall into two categories: 


o Areas that are essentially independent of the other problems and, 
hence, can be addressed immediately, via discrete, minimally 
disruptive changes or improvements to the ’routine’ processes of 
the IETF. 


o Areas that are interdependent and are likely to affect structural 
matters that characterize the way in which the IETF operates. 
Addressing these areas will probably need a more integrated 
approach, as they may require actions such as fundamental changes 
to our organizational structure or standards-track processes. 


It is suggested that the IETF work on these two classes of 
improvements in parallel, so that we can enjoy some near-term 
benefits while more structural improvements are being carefully 
considered and executed. 


Concrete suggestions are included for how we can begin or continue 
work on the independent routine improvements. 


Due to lack of consensus, no firm suggestions are included on how to 
address the more structural changes that may be needed. The document 
lists the various proposals which have been considered by the working 
group and the wider IETF at the IETF 57 plenary session in Vienna, 
July 2003. This document can only suggest, as some participants have 
proposed, that the IESG itself control the development of any 
solutions to the structural problems. 


2. IETF Purpose and Core Values 


As we consider how to address the problems with the IETF processes 
and organizational structure, it is important to keep in mind the 
things about the IETF that we don’t want to change -- our sense of 
purpose, and the core values that give the IETF its unique identity. 


At two IESG plenary meetings in 2002, the chair of the IETF, gave 
presentations outlining his view of the purpose and core values of 
the IETF which may serve as a useful basis for focusing on our 
mission and core values. 
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At the IESG plenary in London in July 2002, it was stated that the 
purpose of the IETF is to "produce high quality, relevant, and timely 
technical standards for the Internet". Our organizational structure 
and processes should be judged by how well they help us to achieve 
that mission. 


At the following IESG plenary in Atlanta, Georgia in November 2002, 
five core values of the IETF were presented [8]: 


"Cares for the Internet" 
"Technically Competent" 

"Open Process" 

"Volunteer Core" 

"Rough Consensus and Running Code" 


2.1. Non-Core Values 


Understanding our core values will also help us to understand the 
long-standing features of the IETF that we can change without 
compromising our values or sacrificing our unique identity. 


During the November 2002 IESG Plenary, the IETF chair also presented 
the following "non-core values" [8]: 


- The division into WGs and Areas 

- The three-step standards process 

- The ASCII format for RFCs and I-Ds 
- The format of IETF meetings 

- The structure of WG mailing lists 
- The powers of the IESG and IAB 


These things were designed to help us achieve our goals in a way that 
is consistent with our core values. If they are no longer effective, 
we can and should change them. 


3. Building on our Success 


while focusing on our operational problems, we shouldn’t forget that 
the IETF is a very successful organization. We are responsible for 
some of the most widely used communications standards in the world, 
and we have contributed to the creation and growth of the Internet, 
one of the greatest technical and social achievements of our time. 


In good times, it is easy to succeed despite operational 
inefficiencies, so organizations tend to ignore operational problems 
and focus on their success. In bad times, organizations can become 
overly critical of their own structure and processes, blaming the 
organization for problems that are actually caused by outside forces. 
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We are currently suffering difficult times in the IETF and throughout 
the communications industry. The IETF should be careful not to 
unjustly blame our own organizational structure or processes for the 
effects of industry-wide changes such as: 


o Economic issues in the global communications industry, which are 
causing increased scrutiny regarding expenses and return-on- 
investment. These same factors are causing job changes and 
uncertainty for many IETF participants. 


o The commercialization of the Internet, which has drastically 
increased the financial impacts of standardization. 


o The convergence of the datacom and telecom sectors of the 
communications industry, which has led to an influx of experienced 
people into the IETF with a different culture and industry 
perspective. 


Although it is important to recognize and correct the serious 
organizational problems currently facing the IETF, many of these 
problems have existed for years, and the IETF has been successful in 
spite of these issues. We should not overreact to these issues with 
sweeping revolutionary changes to the IETF structure and processes. 
Instead, we should focus on developing a culture of continuous 
operational improvement through which we can evolve our 
organizational structure and processes to make them more scalable and 
effective. We should take this opportunity to develop the mechanisms 
and processes that we can use to continually monitor and improve our 
organizational effectiveness, both in good times and bad times. 


The IETF currently has a large amount of valuable work underway, and 
care should be taken not to disrupt or delay that work while we 
address our organizational problems. 


The IETF is also fortunate to have a large number of extremely 
talented and dedicated individuals that serve in formal and informal 
leadership roles throughout the organization. We should be careful 
not to alienate or disenfranchise the IETF’s key contributors and 
those who provide the driving force for the work while making 
organizational or process changes. 


4. Problem Decomposition 
The problem statement document lists seven root cause problems 


currently facing the IETF, without making any judgements about the 
relative priority of the problems (apart from the first one): 
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o Participants in the IETF do not share a common understanding of 
its mission; 


o The IETF does not consistently use effective engineering 
practices; 


o The IETF has difficulty handling large and/or complex problems; 
o The three stage standards hierarchy is not properly utilized; 


o The IETF’s workload exceeds the number of fully engaged 
participants; 


o The IETF management structure is not matched to the current size 
and complexity of the IETF; 


o Working group practices can make issue closure difficult; and 


o IETF participants and leaders are inadequately prepared for their 
roles. 


Analysis of these problems indicates that they can be decomposed into 
several areas for improvement, some of which can be addressed 
immediately by independent actions while others require greater 
consideration and a more structured approach to a solution. 


It is also important to note that the problem statement lists 
problems that have been reported by some members of the IETF. 
Although all of these problems are believed to exist, not all of 
these problems are present in all parts of the IETF, and some of 
these problems may in fact be symptoms of other problems. 


4.1. Decomposition of Mission Problem 


In order to determine the best organization and processes for the 
IETF to fulfill its mission and achieve its goals, the organization 
needs to articulate a common understanding of its current mission and 
goals. Although it should be possible to reach an understanding of 
the mission and goals of the IETF as an independent action, with no 
disruption to current processes, this effort would be most valuable 
as part of an effort to align the organization and priorities of the 
IETF with its mission. 


As part of understanding our mission, the IETF will need to identify 


our stakeholders and understand how we serve them. We will need to 
define the scope of the IETF, so that it is possible to determine 


Davies & Hofmann Informational [Page 6] 


RFC 3844 IETF Problem Resolution Process August 2004 


what is in-scope and out-of-scope for the organization. We will also 
need to define our goals and priorities, and learn how to recognize 
and measure our own progress and success. 


A continuing review of the mission and goals of the IETF needs to be 
undertaken to ensure that they remain aligned with technology 
developments as well as the needs of the industry in general and our 
stakeholders in particular. 


Once an understanding of the mission and goals of the IETF has been 
articulated, we should train new participants on those principles, so 
that they can become quickly acclimated to the IETF culture. 


4.2. Decomposition of the Engineering Practices Problem 


The IETF lacks effective engineering practices in four major areas: 


1. Failure to clearly define the scope of the work, engineering 
trade-offs and acceptance criteria for each project. 


2. Lack of effective mechanisms for issue tracking and/or document 
change control. 


3. Lack of effective processes to ensure quality throughout the 
development of IETF work items, such as intermediate acceptance 
criteria or formal review processes. 


4. Sufficient focus on milestones, and recognition or rewards for 
individuals or groups that achieve timely, high quality 
execution. 


Some of these areas (issue tracking and revision control) would 
require that tools are made available to WG chairs and editors, and 
that IETF participants (at various levels) are educated in how to use 
them. 


The other areas concern the formation and process management of IETF 
WGs, and would require documentation and adoption of effective 
engineering processes within IETF WGs. 


4.3. Decomposition of the Complex Problems Problem 


The IETF has effective mechanisms for dealing with well-defined 
problems of limited scope. These problems are well handled in IETF 
WGs, where experts in a given technology can convene and solve the 
problems specific to one technology area. However, we are much less 
effective at resolving complex problems that affect more than one 
IETF WG or area. 
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Today most communication between WG chairs, especially across area 
boundaries, goes through the IESG. Some inter-WG or inter-area 
communication problems could be alleviated by greater communication 
and coordination directly between the chairs of related WGs. There 
are some immediate efforts underway that are intended to increase 
communication between WG chairs. 


Other complex problems involve higher-level issues, such as unified 
architecture or highly-coordinated multi-area efforts. As part of 
any IETF reorganization, we should consider management structures 
that will allow us to achieve a better focus on architectural and 
cross-area issues. 


4.4. Decomposition of the Standards Hierarchy Problem 


There are several problems with the IETF’s three-track standards 
process. These problems can be grouped as follows: 


o The three standards-track steps are not used effectively within 
the IETF. 


o The IETF standards-track is not well understood by the users of 
IETF standards. 


o The current standards process does not make it easy for users to 
locate a set of related documents, such as an architectural 
framework and associated protocols. 


o The IETF does not have an effective way to maintain IETF 
standards. 


Major changes to the standards-track should only be considered as 
part of an integrated structural review process that includes an 
understanding of our mission and goals. 


However, there may be immediate changes that we could make to better 
maintain current IETF standards, or to make them more accessible to 
users. 


4.5. Decomposition of the Engagement Problem 
The engagement problem can be decomposed into three primary issues: 
o Some WGs do not have sufficient participation, and WG documents 


are often produced by very small groups of people, perhaps with 
limited expertise in some relevant areas. 
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o WG documents are not adequately reviewed by people outside of the 
originating WG. 


o People lose interest in longer-lived WGs, especially when 
protocols take a very long time to develop. 


When too few people, or people representing too few areas of 
expertise, review WG documents this can result in poor quality 
output. We need to find ways to increase the effectiveness of 
document review at all levels. 


Quality processes based entirely on a gatekeeper at the end, whether 
that gatekeeper is the IESG or a WG review board, tend to result ina 
lower focus on quality by other participants. So, it is likely that 
instituting better quality processes throughout document development, 
including acceptance criteria and review at several stages, would 
increase the focus of WG participants on document quality. 


When the interest of document editors or key contributors starts to 
lag, this can cause serious problems for a WG. This most often 
happens when WGs are floundering, or when charters are so loose that 
WGs lose focus. It also happens when WG documents get delayed in AD 
review and/or IESG review for long periods with little feedback, or 
when the WG lacks consensus to progress its documents. Improvements 
to our processes for chartering, tracking or managing WGs could help 
to alleviate many of these problems. 


We also need to better understand what motivates people to become 
deeply engaged in the IETF and to remain engaged. It is possible 
that expanding the number of formal leadership positions and/or 
coming up with more effective ways to acknowledge our top technical 
contributors could encourage more people to become, and remain, 
deeply engaged in IETF. 


4.6. Decomposition of the Management Scaling Problem 


There are several issues grouped into the concept that the management 
structure of the IETF is not well matched to the size and complexity 
of the organization. One or two of these problems might be addressed 
by immediate solutions, but resolving the primary problem will 
require some type of IETF reorganization. 


There are five major areas for improvement that are grouped under 
this problem: 


o The current organization of the IETF does not scale. IESG members 


are running too many WGs, reviewing too many documents, etc. Most 
IESG members have dozens of direct reports (WG chairs, directorate 
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members, etc.). In its current form, there are very few people who 
could do a good job as an IESG member, and the huge time 
commitment and responsibilities of this role make it very 
difficult to find qualified people who are willing to serve on the 
IESG. 


o Current IESG members and other IETF leaders are overloaded. 


o The IETF selection processes have tended to select leaders (IESG, 
TAB and WG chairs) from the same small pool of people. The IETF 
needs to identify and develop additional leadership, and to 
delegate real authority and influence to a larger group. 


o The IETF is not effective at identifying and developing new 
leaders, and we lack sufficient recognition for the contributions 
of IETF participants. 


o One or two IESG members can block WG documents indefinitely (in AD 
review or IESG review). 


Some level of IETF reorganization is needed to improve in the first 
two areas. This should be undertaken as part of the structural 
improvement effort. 


In parallel with any more structural IETF reorganization, some relief 
could be achieved by modifying IESG internal processes to remove the 
potential for one or two IESG members to indefinitely delay a WG 
document, either on purpose or due to work overload. The I-D tracker 
has already resulted in some improvement in this area, as it has 
created visibility regarding how and why a document is being delayed, 
but it may not have resolved all of the issues in this area. 


The IESG may also be able to take near-term steps, with community 
visibility and agreement, to delegate more work to WG chairs, to 
directorates, to the IAB, or to other people in formal or informal 
leadership positions. If additional leadership positions are needed 
for this purpose, the IESG should consider creating them. 


The IESG could also help to expand the leadership pool of the IETF by 
actively seeking interested and qualified people for leadership 
positions, and by using more open processes for the selection of WG 
chairs and other influential positions. 
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4.7. Decomposition of the Working Group Practices Problem 


Although "rough consensus" is considered a core value of the IETF, 
consensus-based decision making works best in smaller groups with a 
common viewpoint and common goals. Somehow we need to resolve the 
apparent conflict between our core values regarding rough consensus, 
and our desire to be an effective organization with several thousand 
participants. 


Although consensus-based decision making has some inherent issues, 
there are some problems in the IETF that exacerbate these issues: 


o WG chairs may lack the skills and training to deal with common 
behavior problems that undermine or prevent consensus. 


o IETF participants are often unaware of how the IETF decision- 
making processes are intended to work. 


o WG chairs and participants often lack good conflict resolution 
skills. 


Each of these issues could be addressed through training or other 
educational resources. 


4.8. Decomposition of the Preparedness Problem 


The IETF could benefit from training and educational resources that 
increase the preparedness of IETF participants and leaders at all 
levels. 


The IETF currently has formal training programs for new attendees and 
for new working group chairs. However, our current training programs 
could use some improvement. There are also several other groups who 
could benefit from training or other forms of development (web 
tutorials, on-line resources, references, mentoring, etc.), including 
continuing attendees, experienced WG chairs, document editors and 
IESG members. 


There is an effort underway to improve the IETF’s internal education 
programs, and we recommend that it be continued. 


5. Process Recommendations 


It is the overall recommendation of this document that we pursue 
near-term improvements to resolve IETF problems of routine in 
parallel with an integrated effort to reorganize the IETF and improve 
our standards processes. None of the efforts suggested in this 
document should be blocked pending the completion and publication of 
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this document. Ongoing efforts should continue, and new efforts 
should start as soon as there is IETF consensus that they are 
worthwhile. 


In our improvement processes, we should attempt to focus our near- 
term improvements on areas of routine that are less likely to be 
substantially modified by any proposed structural changes, thus 
minimizing the likelihood of double changes. 


5.1. Improvements to Routine Processes 


Many of the problems currently facing the IETF can be resolved, or 
mitigated, through near-term improvements to our current IETF 
organization and routine processes. Many of these improvements are 
completely separable, and there is no reason to aggregate these 
efforts into a single IETF WG. It is also unnecessary that all of 
these changes be directed by the (already overworked) IESG. 


However, in order to prevent the chaos and confusion that could be 
caused by trying to change everything at once, it is recommended that 
we choose a few high priority areas for improvement and focus on 
making improvements in those areas. 


In choosing which areas to pursue first, we should consider the 
following criteria: 


o We should address our most urgent, important problems. 


o The areas chosen should be cleanly separable, to allow multiple 
improvements to be carried out in parallel with minimal 
interference. 


o We should maximize the benefit vs. the cost of making the 
improvements (i.e., look for low hanging fruit). 


o As much as possible, we should focus on improvements that are less 
likely to be completely invalidated by an overhaul of the IETF 
management structure. This might be accomplished by focusing on 
improvements at the WG and participant levels, rather than at the 
IESG/IAB level. 


In the sections above, we have identified several areas of routine 
that could benefit from near-term improvements, including: 


1. Improve WG quality processes and the effectiveness of document 
reviews at all levels. 
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2. Increase the availability and use of issue tracking and document 
sharing/revision control software in the IETF. 


3. Improve training and resources for IETF leaders and participants 
at all levels. 


4. Improved communication between WG chairs to identify and resolve 
inter-WG and inter-area problems. 


5. Consider IETF processes or structures to better maintain IETF 
standards. 


6. Modify IESG-internal processes to make it impossible for one or 
two IESG members to indefinitely delay a document. 


7. Modify IESG processes to delegate more responsibility to WG 
chairs, to directorates, to the IAB or to people in other formal 
or informal leadership positions. 


8. Modify the WG chair selection processes to widen the group of 
people considered, and consider ways to develop more leaders for 
the IETF. 


9. Initiate regular AD review of WG milestones and progress. 


Applying the criteria outlined above, it would make the most sense to 
address areas 1, 2, 3, 4, and 5 through immediate near-term efforts. 
These are high-priority issues, they are sufficiently separable to be 
pursued in parallel, they place minimal additional burden on the 
IESG, and they are the least likely to be affected by an 
IESG/IAB-level reorganization of the IETF, or by changes to the 
standards-track document maturity level classification and process. 
Specific recommendations for how to proceed in each of these areas 
are made in the following sections. 


The IESG should consider internal changes to address areas 6, 7, and 
8. Area 9 would require a substantial time commitment from IESG 
members, so it is not suggested that near-term improvements be 
pursued in this area, unless the IESG believes that the near-term 
benefits would justify the effort. 


.1. Suggestions to Improve WG Quality Processes 


A working group should be formed in the General Area of the IETF to 
oversee improvements to the WG quality processes, including: The WG 
(re-) chartering process, the quality processes used by IETF WGs, and 
the effectiveness of IETF reviews at all levels. It should be the 
goal of this WG to improve the quality and timeliness of WG work 
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output. This WG would be chartered to resolve the non-tools-related 
portions of the Engineering Practices problem (Section 4.2) the WG- 
related portions of the Engagement Problem (Section 4.5), and the 
non-training-related portions of the WG Practices problem (Section 
4.7). 


A great deal of efficiency and synergy can be achieved by adopting 
common processes throughout an organization. However, it is a 
strength of the IETF that WG chairs are given a great deal of 
latitude to choose their own processes and tools, based on the size 
and nature of their WGs. So, in general, processes and tools should 
be made available to WGs and WG chairs, not forced upon them. 


5.1.2. Suggestions to Increase the Use of Tools 


Ideally, the proliferation of tools within the IETF would be 
accomplished via grass-roots efforts, organized by participants 
within the IETF. One example of this type of effort is the recent 
adoption of Jabber for use during IETF meetings. 


However, it is also possible that the IESG could designate functional 
leaders for specific tools-related efforts and support those leaders 
in organizing those efforts. It also might be helpful for the IETF 
to set-aside some technical and systems resources, to make useful 
tools available to WGs and participants throughout the IETF. 


These efforts should resolve the tools-related portions of the 
Engineering Practices problem (Section 4.2). 


5.1.3. Suggestions to Improve Training 


The current WG chairs and newcomer’s training efforts should be 
continued and expanded as appropriate to cover training for other 
groups. This effort is expected to address the Preparedness problem 
(Section 4.8), and the training-related portions of the Mission 
Problem (Section 4.1) and the WG Practices problem (Section 4.7). 


5.1.4. Suggestions to Increase WG Chair Communication 


Some efforts are already underway to allow WG chairs to meet each 
other, and to give them opportunities to establish communication 


channels. These efforts include WG chair socials and training 
sessions for experienced WG chairs. These efforts should be 
continued. 


The IESG could help to promote chair-to-chair communication by 
encouraging direct communication between WG chairs when multi-WG 
issues arise. 
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However, most of the responsibility for establishing effective 
chair-to-chair communications channels lies with the individual WG 
chairs. We should stop relying on the IESG to resolve inter-WG 
issues, and start communicating with each other directly regarding 
inter-WG issues. 


These efforts may help to alleviate the Complex Problems problem 
(Section 4.3), although a comprehensive solution to that problem 
would probably require some changes to the IETF management 
structures. 


5.1.5. Suggestions to Improve Maintenance of Standards 


The IETF should consider proposals to improve the way that IETF 
standards are maintained. It might be possible for the IESG to 
document and implement a mechanism to maintain IETF standards without 
the need for a WG to enact this change. 


This effort should address the maintenance-related portions of the 
Standards Hierarchy problem (Section 4.4). 


5.2. Changing the Structure and Practices of the IETF 


A significant number of the issues that were identified in the IETF 
Problem Statement appear to require alterations to the structure of 
the IETF and/or the core practices which effectively characterize the 
IETF. From the analysis in Section 4 the problems which might 
require such alterations include: 


o The Mission Problem (Section 4.1, [7]), 

o the Complex Problems problem (Section 4.3, [3], [6]), 

o the Standards Hierarchy problem (Section 4.4, [4]), 

o the Management Scaling problem (Section 4.6, [6], [3], [2]), and 


o The longer-term portions of the Engagement Problem (Section 4.5, 
[5]) 


(Additional references on each item indicate associated documents 
that may need to be updated as a result of this process.) 


Poorly thought through changes to these areas could result in 
irretrievable damage to the nature and effectiveness of the IETF, but 
it seems essential that the necessary changes are identified and 
accepted by the IETF community as quickly as possible. To achieve 
acceptance by the largest possible number of IETF stakeholders, as 
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many of them as possible should be involved in the development of the 
changes; the development and acceptance processes must be as open as 
possible in line with normal IETF principles. 


Development of the required changes under the aegis of a General Area 
Working Group was extensively debated and a proposal was floated ina 
previous version of this document. The proposal included a draft 
charter for the working group. This way forwards has now been 
rejected by the Problem working group because of 


the perceived slow progress of such groups, 


the difference in the nature of the problem from the usual 
technical problems solved by IETF working groups and 


the difficulty in achieving acceptance by all segments of the 
community for work driven by a small group. 


A proposal for coordination of the development of the structural 
changes by a ’Strategy and Answers Panel’ composed of delegates from 
IESG, IAB, and ISOC plus a number of members from the wider IETF 
community (forming a small majority of the panel) selected using the 
nomcom selection process can be found in [9]. The selection process 
was intended to create a panel which would represent the interests of 
the whole IETF community and so build solutions that would be 
acceptable to the whole community. This proposal has not received 
extensive support from the Problem working group either. 


Other proposals advanced in discussions are: 


o Delegation of the development of solutions to a team of ’wise men’ 
appointed by the IESG. 


o Development of solutions by a design team with final approval by 
the IESG. 


o Development and implementation of the solutions by the IESG. 


Discussions of alternative processes on the mailing list, at the 
Problem WG meeting at IETF 57 and in the IETF 57 plenary did not 
reach a consensus. Indeed some contributors took the view that the 
problems could be overcome without (major) structural changes. 


Given the lack of consensus and the lack of additional responses to a 
previous appeal for alternative suggestions, this document has to 
fall back to asking the IESG to take responsibility for controlling 
the development of solutions to the structural problems identified 
where it believes they are necessary. 
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6. 


Conclusion 


The IETF has problems, and we need to work to solve those problems, 
both via focused immediate improvements and possibly via an 
integrated effort to build an IETF organizational structure and 
develop processes that can better handle our current size and 
complexity. 


However, the IETF is also an effective organization with a long 
tradition of excellence, and core values that we don’t want to 
compromise in the course of improving our organization and processes. 
So, any major changes undertaken in the IETF should include an 
articulation of the IETF’s mission and our core values, so that we 
can ensure that we build an organization that can carry out our 
mission working in line with our core values. 


The Problem WG has not been able to come to a consensus on a process 
that could address the structural changes that may or may not be 
needed. This is perhaps in line with previous experience of the 
discussion of high level concepts in the IETF - the organization is 
in general much better at discussion of and achieving consensus on 
detailed concrete proposals. This document has little alternative 
but to suggest that the IESG control the development of solutions to 
any of the structural problems where they feel that changes are 
necessary. 


In the meantime, this should not be seen as gating discussions on 
actual solutions for these problems - for example, the active 
discussions that are in progress on alternatives to the current 
maturity level system for IETF standards. Authors of solutions 
should bear in mind the points made in Section 3: Evolutionary 
rather than revolutionary proposals are more likely to be acceptable, 
and an orderly transition must be possible. 


Working together, we can resolve the problems currently facing the 
IETF and make the IETF an even more effective, successful, and fun 
place to work. 


Security Considerations 


This document contains suggestions for processes that the IETF could 
use to resolve process-related and organizational problems with the 
IETF. Although the structure and quality of the IETF’s processes may 
have an affect on the quality of the IETF’s security-related work, 
there are no specific security-related issues raised in this 
document. 
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